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ABSTRACT 


The design of a LISP interpreter that allows tail-recursive procedures to be 
interpreted iteratively is presented at the machine-language level. 
Iterative interpretation means that, without any program transformations, no 
environments and continuations will be stacked unless necessary. 


We apply a specific modification within a traditional stack-oriented version 
of LISP interpreter, without any non-recursive control structure. The design 
is compatible with value-cells as well as a-lists LISP processors. 


We present a complete modified interpreter written itself in LISP and an 
informal proof that it meets its requirements. 
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1.0 INTRODUCTION 


It is well-known that tail-recursive procedures (TR for short) are formally 
equivalent to iterative procedures (ij. Unfortunately, when interpreted, 

TR code behaves as ordinary recursive code, and we do not obtain the benefit 
of the formal equivalence. We need a way to make the formal equivalence also 
a practical one. 


The problem of the computation of TR procedures can be stated in terms of 
program transformations, or in terms of interpreters specially designed to 
handle them properly. 


Static program transformations (4, 10] from TR to iterative programs are mainly 
used on compiler~oriented LISP systems, and therefore do not allow full access 
to interpreter-oriented tools of debugging, breaks, traces etc. Moreover, as 
they are name~sensitive, they cannot handle procedures with circular types. 


Interpreter-oriented processing of TR pror duces uses non-recursive control 
structures like message-passing as in Hewitt's ACTORS system(7, 8 | or generalized 
FUNARG devices with static a-lists, as in Sussman's SCHEME (12]. Also delayed 
evaluation of CONS [6 has been proposed in-which partial building of a struc- 
ture is triggered by invocations to the decomposition primitives CAR and CDR 
applied to this virtual structure. 

As interesting as they are, there do not seem to be any evident ways to adapt 
such methods to ordinary | recursive stack-oriented LISP interpreters. 


In contrast, we propose a simple way to process TR procedures iteratively, 
without any program transformations or non~-recursive control structures. Our 
scheme can be used with a-lists as well as value-cells stack-oriented LISP 
interpreters. 


2.0 TAIL RECURSIVE SCHEMATA 


In [Y a TR schema in iterative form is defined as a recursion equation 
f(xl,...,xn) = g(f,xl,...,xn,hl,...,hm) 


where g is a conditional expression defining f in terms of the functions 
ht,...,hm3 g is said to be iterative if f occurs exactly in terms of g in 
the form THEN f(...) or ELSE f(...). 


For example, this is the recursive form of the well-known program for 
addition (NOTE 1!) 


(de plus (x y) (if (= x 0) y. 
(add! (plus (sub! x) y)))) 


and this is the corresponding iterative form 


(de plus (x y) (if (=x 0) y 
(plus (subl x) (add! y)))) 


NOTE 1: (if c el e2'... en) is the LISP equivalent to the form 


tf c then el else e2; ... 3 en fi 
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We must generalize the previous definition of iterative schema to any named 
A-expression such that i 


(1) £ = {(å(xl...xn) ... (£ al...an)) | (NOTE 2) 
i.e. the last term of the h-expression body is a call of this A\-expression. 


(2) £ = CACxi...en) ... (ifc (f ai...an) ...)) 
and | 
£ = ( AGxl...xn) ... (if c el e2 ... (£ al...an))) 


j.e. the THEN-parc or the lasc term of the ELSE-part of an if-form is a cail 
of this \-expression. 
Nested if~-forms are valid under this schema, e.g. 


f= (A(xl...xn) o. GE et (GË c2 2... Cif cm (E al...an) ...) ...))) 


(3) £= ( A\(xt..exn) ... (cond ... (c el ... em=1 (£ al...an)) ...)) 


Note that the condition c, even if it consists solely of the constant T, must 
be mentionned explicitely, in contrast with for example INTERLISP [13 | style 
of writing CONDs. | | o 


3.0 RETURN CONTINUATIONS 


We notice that these schemata share a common property: all of them are instances 
of forms interpreted by the LISP system internal function PROGN. 


These forms will be interpreted recursively if PROGN is defined as follows. 

‘ Let us suppose the variable EXP is the name of a register which contains the 

| form to be evaluated and the result after the evaluation. TEMP is a working 
register, SAVE and RESTORE push and pop respectively their argument onto a 
stack, REC pushes a return continuation (NOTE 3), and UNREC restores the current 
continuation from the stack. | 


PROGN = Leumptexp; 
| while not (null (temp)) 


do save(temp); exp+car(temp); 
rec EVAL; temp+restore(); 
temp+cdr (temp) 
od 
unrec(); 
a NOTE 2: This part of the definition means that we allow non-terminating 
P procedures. | 
i | 
$ NOTE 3: Here we use the continuation concept fis] the same way as in (9), where 


a continuation is just a list of instructions to be executed, 
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On the contrary no return continuation will be stacked at an instance of a 
TR call of our iterative \-expressions if PROGN is designed as: 


PROGN = whtle not(null(cdr(exp) )) 
do save(exp); exp+car(temp) ; 
rec EVAL; exptrestore(); 
exptcdr (exp) 
od 
exptcar(exp); jumpTo EVAL; 


The last clause of a PROGN argument (a list of expressions to be evaluated) 
will be passed directly to EVAL, which obtains the definitive control of the | 
continuation. 


If LISP TR procedures had no arguments, the interpreter would automatically 
handle calis of forms like 


fe (AQ) Gif c el e2 ... enn] (£))) 
as 


while not c do eval(e2); ...; eval(en-1) od; 
eval(el); 


Then the program writer could design its procedures in the most natural way, 
without paying attention to what are necessary or unnecessary recursions [14]. 
But, as LISP procedures generally use argument passing, we need a way to omit 
unnecessary saving of environments (NOTE 4) by the internal LISP system function 
APPLY, in the case of TR procedures. 


4,0 THE HANDLING OF ENVIRONMENTS 


A redundant environment is defined as a new anvironment caused by the call of 
a TR procedure, the old environment being unnecessarily saved, in spite of the 
fact that it will be never used again. 


To avoid redundant environments, we have to modify APPLY in the following 
manner. | 

When APPLY has discovered that it must handle a \-expression, first it examines 
the stack at a definite place to see if the same A~-expression has been called 
before. If this 1s the case, it does not save the current environment onto the 
stack, and just binds every variable of its formal arguments list to tts value, 
then gives the body of the A~expression to PROGN. If this is not the case, 

then APPLY saves the current environment (which means that the A-expression is 
called for the first time, as far as APPLY can see) onto the stack, then saves 
the list which represents the A-expression being called, then builds-a new 
environment as before, and finally saves a return continuation to a part of 
APPLY which restores environments. The control is then given to PROGN. 
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The definite element which APPLY examines is then the next-to-last item saved 


in the stack. 


This part of APPLY can be designed 
the value-cell of LISP variables) 


in the following manner (the field CVAL being 


* 
2 


PART-OF~APPLY = ¿f car(exp)=A tken 
tf STACK(TOP-1] =exp then 
for~-each x tn cadr(exp) do 


x.CVAL+car(arglist) ; 
arglist+«cdr(arglist) 
od : 


exp+cddr (exp); jumpTo: PROGN 


else 


save(sentinel); 
for-each x tn cadr(exp) do- 


save(x.CVAL); save(x); 
x. CVAL+car(arglist); 
arglist+cdr(arglist) 
od | 


save(exp); exp+cddr(exp); rec PROGN; 
restore(); | 


wht le stack| Top} 4 sentinel do 


od 


a) 
+e. 


x@restore(); 
x.EVAL+restore() 


restore(); unrec() 


NOTE 4: By environment is meant an association of variables with values. 
In LISP, saved environments can take the form of a-lists, where the 
value of every variable is found (with the possibility of multiple 
instances of the same variable), or can take the form of value-cells, 
in which case the value associated with the variable is unique and 
immediately accessible, old associations being saved on the stack. 
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5.0 EXAMPLES OF TR-PROCEDURES 


Here are some examples to illustrate programming in TR style, with the 
modified interpreter. 


(1) An iterative Ackermann function : 


(de ack (x y) (a x y nil)) 


(de a (x y p) (cond 
((= x 0) (if p (a (car p) (add! y) (cdr p)) 


(add! y))) 
((= y 0) (a (sub! x) i p)) 
(T (a x (subi y) (cons (subl x) p))))) 
(2) Building a list of factorials : 
(de factlist (n) (gn I (list 1))) 
(de g (n x r) 
(if = xn) r = 
(g n (addi x) © 
(cons (times (add! x) (car r)) r)))) 
(3) Building a factorial procedure with circular type : 
(setą g "CO. (x y f) 
GE (= x 0) y 
eed a (subi x) (times x y) £))))) 


to obtain factorial n we call ((car g) n 1g) 
Our modified interpreter appears to be “name~insensitive’ and can 
© run this example iteratively, which cannot be handled by program 
transformations. 
(4) Notice that forms like 


(Cd (x) (x x)) 'A (x) (x x))) 


being run iteratively do not cause overflow of the stack. 
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6.0 THE MODIFIED INTERPRETER 


Here is the complete modified LISP interpreter (NOTE 5). It is written 
itself in LISP in the machine language style of Sussman's SCHEME 12). 
We use a global environment and we do not use any recursive features. 


(de run () (setq pe 'toplevel) (loop)? 


(de toop () (whtle t (apply pe ntl))) 


We use a non-terminating control loop which runs the “next” procedure, 
in which the non-modified LISP internal function apply is called over and 
over again. The variable pc plays the role of a PORTAI COMETRE: 

. Here is the top-level loop : 


(de toplevel () (setq link nil stack nil) (save "opt 
(setą exp (read) pe ‘eval)) 


(de ai () (print exp) (setq pe 'toplevel)) 
Here are the "pipe~lined" procedures eval, evlis and apply + 


(de eval () (cond 
((numberp exp) (unrec)) 
((atom exp) (setq exp (car exp)) (unrec)) 
(T (setq hdexp (car exp) exp (edr exp) pe ‘evali)))) 


(de evall () (cond 
((ltstp hdexp) (save eve) (setq pe levlts)) 
((or (get hdexp 'expr) (get hdexp 'subr)) 
(save hdexp) (setq pe 'evlts)) 
((setq temp (get hdexp 'fexzpr)) 
(setq argltst (list exp) exp temp pe ‘apply)) 
( (get hdexp 'fsubr) (setą pe hdexp)) 
(T (setq hdexp (car hdexp))))) 


(de evlts () (setq butlt nil pe ‘evlisl)) 


(de evlts1 () (tf (null exp) 


(setq argltst (reverse built) exp (restore) pe 'apply) 
(save exp) (save butlt) (save 'evlis2) 
(setq exp (car exp) pe ‘evat))) 


(de evlts2 () 
(setq pet (eons exp (restore)) exp (edr (estore) pe ‘evits1)) 


NOTE 5 : This eroen is in fact a simplification of the one running 
under the name of VLISP at the University of Vincennes [2, 5 | on 
a PDP t0 and a T1600 computer. © 
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(de apply () (eond 
. {((atom exp) (cond 
((setq temp (or (get exp 'expr) (get exp 'fexpr))) 
(setq exp temp)) | | 
((or (get exp 'subr) (get exp 'fseubr)) 
(setq pe exp)) 
(T (setq exp (car exp))))) 
((or (eq (car exp) (setq temp 'd)) 
(eq (car exp) (setq temp 'y))) 
(setq \~y~exp exp) . 
(tf (eq temp 'y) (setq arglist (car arglist))) 
(Gf (eq (cadr stack) \~y~exp) | 
(rebind (cadr \~y-exp) arglist) | 
(bind (cadr \-y~exp) arglist) (save \~-y-exp) (save ‘apply3)) | 
(setq exp (ceddr -y-exp) pe 'progn)) 
(T (save arglist) (save ‘apply2) (setą pe 'evat)))) 


A form (y(xl...xn) el e2 ... en) is like a A~expression but when applied 
to an argument which is a list, it distributes the elements of this list 
over the formal arguments x1...xn . This is -very efficient for handling 
multiple values recursive procedures. E 
(de apply2 () (setq arglist (restore) pe 'apply)) — 

ian | | iE 
(de apply3 () (restore) (unbind) (unrec)) 
The internal procedure unbind restores old environments, rebind simply 


builds a new environment without saving the current one in contrast to 
bind which saves the old environment. | | 


Next we come to the "sequencer" procedure progn : 
(de progn () (tf (edr exp) nil (save exp) (save 'progn1)) 
(setq exp (car exp) pe ‘eval)) 


(de progni () (setq exp (edr (restore)) pe 'progn)) 


Finally, as an illustration of control procedure of FSUBR type, we give the 
code for tf: 


(df tf 0) (save exp) (save 'tf1) (setq exp (car exp) pe ‘eval)) 


(de if1 () (if exp (setq exp (cadr (restore)) pe ‘eval) 
(setq exp (eddr (restore)) pe 'progn))) 
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7.0 CHECKING-RULES 


+ 


We must now devise a means of insuring that our interpreter meets its 
requirements. We shall use "checking-rules" of the form 


Si{P1}P2:S2 


where Sl is the state of the stack when entering procedure Pl, S2 is the state 

of the stack when leaving procedure P!, and P2 is the name of the next procedure 
to enter. When P2 is the label "retcont” it means that Pl has no next procedure 

to enter, so a recursive return to the head of the stack has to be performed. 


Examination of the interpreter yields the following rules, which constitute 
in a sense an abstract version of the interpreter, the enter and exit states of 
the stack playing the role of an history [3]. 


a{eval}retcont:a y evallia 
afevall}evlis:hdexp:o y applyta vfsubria yevall:a 
hdexp:afevlisjevlisl:hdexp:a 
hdexp:a{evlis]}eval:evlis2:built:exp:hdexp:ay apply:a 
built:exp:hdexp:afevlis2}evlis|:hdexp:a 
a{apply}apply:ay subr:ay fsubria 


v progniay progn: apply3:\-y~exp:oldbindings:a 
Veval:apply2:arglist:a ` | 


arglist:a{apply2}apply:a 


\~y-exp:oldbindings:a{apply3}retcont sc 


8{prognieval:prognl:exp:B vy eval:8 
exp: 8{progn!}progn: B 


Blif}seval:ifl:exp:8 (NOTE 6) 
exp: 6{iflleval:8v progn: 3 


Using the checking-rules, we can show that the interpreter handles TR programs 
correctly. 


let foo = (A (xl ... xn) el... em) 


with em = (foo al... an) 


First of all we must show that the stare of the stack is the same when evaluating 
em and when entering progn with exp = (el ... em) 


NOTE 6 : Recall that tf is of FSUBR type. 
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Let exp = (el we. em) with af{progn}. 


Suppose m = Í, we have’ 

a{progn}eval:a and therefore a{eval}. 
If m> |} we have > 

a{progn}eval:progniiexp:a 


and if the evaluation of the head of exp does not enter into an infinite 
loop, we shall obtain 


exp:a{progn!}progn:a 
followed by l 
a{ progn} , now with the length of exp being a! e 


Further, we must show that when 
apply3: foo: oldbindings: aval 


then exp = em , i.e. it is only when evaluating ew that we can find foo 
as the aa ei item in the stack. 


Suppose exp =” ek with k m. The state of the stack when SnEETLNE eval 
meat be 3 , | 


progni: (ek. TE an: steval} 


and (ek ... em) being a tail of foo cannot be equal to foo a. 
Finally we eee show that, if there is not an infinite loop when evaluating 
one of the ei , 1 < i < m, the old bindings will be restored. 
As before, if exp = em, with 
apply3: foo:oldbindings:af{eval } 
when eval returns, the state of the stack is 
foo:oldbindings:a{apply3}retcont:a 


and apply3 restores the environment immediately preceding the first call of 


foo C- 
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8.0 CONCLUDING REMARKS 


We have proposed a LISP interpreter in which TR code behaves at run-time 
as efficiently as well-written iterative code, wich the extra benefit of 
avoiding explicit side~effects as well as manual or automatic program 
transformations. 


Another advantage is that it is insensible to renaming, e.g. if we have 


(de foo (x) ... (foo (2g x))) 


and we perform 


(put "fie (get "foo expr) "expr) 


Ld 


then the call (fie a) will be interpreted exactly the same way as a call 
of foo. 


The modification we have proposed does not depend on particular implemen- 
tations of environments. This one more encouragement to write programs in 
recursive style, particularly since our modification can be applied very 
easily with no apparent drawbacks to any LISP interpreter. 


kd. Notes The whole thing has been imeroved since 1976, It can 
run the same way eet COTTECLITGIVe Froceduresy aries 
also what I call "envelored" tail-recursions, as ir 


CHE foo (x 
Ctr CZEROP w) O 
Chow (foo (SUBI x))))) 


ACKNOWLEDGEMENTS 


Many discussions and advices from J. CHAILLOUX have been very helpful, 


as well as the material help he provided during the preparation of this 
report. 


htto://Awww.artinfo-musinfo.org Lisp Bulletin # 2, July 1978, page 49 / 52 


htto:/Awww.artinfo-musinfo.org Lisp Bulletin # 2, July 1978, page 50 / 52 


REFERENCES ~46- 


l. J. McCARTHY : “Toward a mathematical science of computation." 
Proc. IFIP 1962 21-28 ee 


2. CHAILLOUX J. : "VLISP 10" RT 17-76 
Computer Sc Dept. University of Vincennes. France. 


3. M, CLINT : "Program Proving : Coroutineés” 
Acta Informatica 2, 50-63 (1973) 


4.° DARLINGTON J., BURSTALL R.M. : "A system which automatically improves 
programs." , (1973) 


Proc. of 3. International Joint Conference on Artificial Intelligence. 
Stanford. 537-542 


5.  GREUSSAY P. : "Descriptions compactesd’interprétes implémentables." 


Programmiug Symposium. Paris. Avril 1976. 
B. Robinet ed. 281-297 


we 


6. FRIEDMAN D.P., WISE D.S. : "Output Driven Interpretation of Recursive 
Programs.” | 


TR n°50. Indiana University. July 1976. 


7. C. HEWITT : "Behavioral semantics of noprecursive control structures" 
Proc. Programming Symposium. Paris. 1974, 
B. Robinet ed. Springer-Verlag. 385-407 


8. C. HEWITT : "Viewing control structures as patterns of passing messages" 
Working Paper 92. April 1976. MIT AI Lab. 


9. REYNOLDS J.C. : "“Definitional interpreters for higher-order programming 
languages." | : 
Proc of !972 ACM Nat. Conf. Boston. 1972. 717-740 


10. RISCH T.: "REMREC : A Program for automatic recursion removal in LISP." 
‘Uppsala University. 1973 


Mt. STRACHEY C..: "A mathematical semantics which can deal with full jumps" 
. Séminaires IRIA "Théorie des algorithmes, des langages et de la 
programmation" ed. M. NIVAT. Mai 1973. 175-191 
12. SUSSMAN G.J., STEELE Jr G.L, : "SCHEME : An interpreter for extended 
Lambda-calculus." 


MIT AI Lab. AL Memo n° 349. Dec 1975 


13. TEITELMAN W. : “Interlisp Reference Manual." 
XEROX Palo Alto Research Center. 1974 


14, WIRTH N. : “Algorithms + Data Structures = Programs" 
Prentice Hall. 1976 


SENT MORE TECHNICAL NOTES) 


htto:/Awww.artinfo-musinfo.org Lisp Bulletin # 2, July 1978, page 51 / 52 


